There arise many instances where the data values associated with one application running on a data processing apparatus are sensitive data values that should not be accessible to other applications. It is clearly important in such situations to ensure that such sensitive data is kept secure so that it cannot be accessed by other applications that may be loaded onto the data processing apparatus, for example hacking applications that have been loaded on to the data processing apparatus with the purpose of seeking access to the sensitive data. This can be a particular concern where the applications share a cache.
It is known to provide a system in which the data processing apparatus is provided with separate domains, these domains providing a mechanism for handling security at the hardware level. Such a system is described for example in commonly assigned co-pending U.S. patent application Ser. No. 10/714,561, now U.S. Pat. No. 7,305,534 this application describing a system having a secure domain and a non-secure domain. In that system, the non-secure and secure domains in effect establish separate worlds, the secure domain providing a trusted execution space separated by hardware enforced boundaries from other execution spaces, and likewise the non-secure domain providing an untrusted execution space.
Software cryptographic systems on multi-processing systems that use shared caches are generally viewed as not secure as there is a potential for information leakage to occur between the processes due to them both sharing a cache. A cache is to some degree transparent to a programmer in that it decides itself where to store data. Known secure systems such as the one described above can prevent a non-secure process storing data in a cache from accessing data stored in the cache by a secure process. However, information regarding the data access pattern of one process can be derived by the other process and this information may be sufficient to allow the security of say a cryptography system to be compromised.
FIG. 1 schematically shows a cryptographic process running in a secure part of a system, and an untrusted process running on a non-secure part of the system. Switching occurs between the processes as each competes for processing time. The untrusted process cannot access data stored in the cache 60 by the cryptographic process. However, it can derive an access pattern of the cryptographic process, by saturating the cache 60, and then following execution of a portion of the cryptographic process, accessing the cache 60 to read the data it saturated the cache 60 with. Access times for this data will tell the untrusted, or in this case hacking, process whether or not the cryptographic process has overwritten that piece of data or not, thus the set of cache lines accessed by the crytopgraphic process can be identified by the hacking process. In the case that the cryptographic process is one using data lookup tables this may be sufficient to enable the encryption to be broken. This is described in detail in “Cache-Collision Timing Attacks Against AES” by Bonneau and Mironov, http://www.stanford.edu/˜jbonneau/AES_timing.ppt, and “Cache Attacks and Countermeasures: the case of AES” by Osvik, Shamir and Tromer, http://www.wisdom.weizmann.ac.il/˜tromer/.
There are a number of potential solutions to this problem, some of which are described in these documents. For example, in a system having a secure domain for running secure trusted processes and a non-secure domain for running untrusted processes the cache could be flushed on switching between these domains. This is clearly expensive on performance and power.
Alternatively, caches could be divided in that a part of the cache could be statically allocated to a particular domain this would have performance implications. Alternatively, caches could not be used at all, if caches were not to be used, a tightly coupled memory could be used for the lookup tables instead. A drawback of this is that these memories are typically not large. If the tables were permanently stored in the tightly coupled memory then this would use a lot of this restricted memory space, however, if they were copied in when required this would be expensive on performance and power.
Another alterative would be to calculate the lookup tables on the fly, however, this would be slow and would incur a significant power cost.
It would be desirable to impede leakage of information regarding cache access behaviour of a section of a sensitive process to an untrusted process without incurring too large a power or performance overhead.